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ABSTRACT 



A remote proxy generator (300) generates a remote proxy 
class for use in client-side communications for communi- 
cations between a client application (108) and a server 
object (110). A client-side type generator (302) generates a 
type object (174) that represents a class of the server object 
(110) and provides access to methods (190) of the server 
object (U0). A client-side function generator (304) gener- 
ates one or more function objects (172) corresponding in 
number to one or more methods (190) of server object (110). 
A client-side reference generator (306) generates a reference 
object (158) for managing encoding of messages sent 
between a remote proxy object (154) and the server object 
(110) into a format of a communications protocol used by a 
server-side object request broker (114). A client-side 
streamer generator (308) generates a set of streamer objects 
(180) corresponding in number to the one or more methods 
(190) of the server object (110). Each streamer object (190) 
encodes a method invocation request for an associated 
method (190) of the server object (110). A server-side local 
reference generator (310) generates a local reference object 
(202) that includes an address and a type of the server object 
(110), A server-side type generator (312) generates a type 
object (204). 

25 Claims, 7 Drawing Sheets 
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SYSTEM AND METHOD FOR DISTRIBUTED 
PROCESSING IN A COMPUTER NETWORK 

TECHNICAL FIELD OF THE INVENTION 

This invention relates in general to the field of software 
systems, and more particularly to an improved system and 
method for distributed processing in a computer network. 

BACKGROUND OF THE INVENTION 

Object oriented programming is a method of program- 
ming that abstracts a computer program into manageable 
sections. The basis of object oriented programming is the 
concept of encapsulation. Encapsulation is a methodology 
that combines the subroutines, or methods, that manipulate 
data with the declaration and storage of that data. This 
encapsulation prevents the data from arbitrarily being 
accessed by other program subroutines, or objects. When an 
object is invoked, the associated data is available and can be 
manipulated by any of the methods that are defined within 
the object to act upon the data. The basic component of 
encapsulation is a class. A class is an abstraction for a set of 
objects that share the same structure and behavior. An object 
is a single instance of a class that retains the structure and 
behavior of the class. Objects also contain methods that are 
the processes that instruct an object to perform some pro- 
cedure or manipulation of data that the object controls. 
Classes may also be characterized by their interface which 
defines the elements necessary for proper communication 
between objects. 

Distributed computing allows an object in a first computer 
system to seamlessly communicate with and manipulate an 
object contained in a second computer system when the 
computers are connected by a computer network. The sec- 
ond computer system may also be referred to as another 
address space. Sophisticated distributed computing systems 
have removed the communications burden from the com- 
puter programs, or objects in an object oriented program- 
ming environment, and placed it in a mid-level operating 
system that manages communications across a computer 
network to facilitate a client system's (first computer 
system) access to and manipulation of data contained on a 
server system (second computer system). The server system 
could be a computer in a different address space and remote 
to a user on the client system. 

Distributed computing and object oriented programming 
have led to the development of distributed object manage- 
ment systems. These distributed object management systems 
are generally referred to as object request brokers (ORBs). 
When an object on a client computer system requests access 
to an object that exists on a server computer system, the 
distributed object management system provides the commu- 
nication link between the two computer systems and, thus, 
between the two objects. The distributed object management 
system removes the requirement of the client object com- 
municating directly with the server object. Instead, current 
distributed object management systems utilize a remote 
proxy object on the client system which models the interface 
of the server object. The client computer system that 
requested access to the server object communicates with the 
remote proxy object that exists on the client computer 
system. Therefore, the client computer system can operate as 
if it is communicating directly with a local object. The 
remote proxy object contains the necessary communications 
information to allow the client computer system to access 
and manipulate an object that actually exists on the server 
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computer system. Remote proxies allow the client system to 
disregard the location of the requested object and the com- 
munication details. 
A proxy is an object that has an interface and method list 

5 identical to another object. However, it does not contain the 
same detailed computer code. Instead it contains communi- 
cations requirements that allow the proxy to communicate 
directly with another object without knowledge of the 
requesting object. Proxies can be used to control access to 

10 certain objects. They may also be used to remove the labor 
of distributed processing communications from local 
objects. For example, if object A residing on a first computer 
system needs to communicate with object B residing on a 
second computer system, object A must know the location of 

35 object B and have the necessary computer code to initiate 
communications with object B. A proxy for object B located 
on the first computer system allows object A to simply 
communicate with the proxy of object B as if object B 
resided on the same computer. The proxy for Object B has 

20 all the necessary information and computer code to com- 
municate with the real object B on the second computer 
system. This type of proxy is known as a remote proxy since 
it exists on a computer system remote from the computer 
system that contains the requested object. 

25 Systems heretofore known have required all possible 
remote proxies to be built when the software system is 
initially compiled and loaded onto a computer. This process 
can be very time consuming and the resultant remote proxies 
can require large amounts of computer storage. In addition, 

30 software system designers must predict every possible 
remote proxy that may be needed in the future so that it can 
be built when the software system is loaded. This process 
does not allow a system to adapt to its usage and environ- 
ment. 

With the rise of distributed computing systems, client/ 
server computing, and internet/intranet interactions, inter- 
node communications between applications and objects has 
become a necessity. Early operating systems lacked support 

4Q for inter-application communications, forcing software 
developers to write custom code to perform a remote pro- 
cedure call for each and every application that needed 
remote communications. 
Distributed computing systems often use a client/server 

45 architecture. Typically, a client is an application that runs on 
a personal computer and relies on a server to perform some 
operations. The server is a computer on a network that 
manages network resources such as storage devices, 
printers, or network traffic. Client-side operations are those 

50 occurring on the client-side of a client/server system. For 
example, on the Worldwide Web, applets may be down- 
loaded and executed on a client and are client-side opera- 
tions. Server-side operations occur on the server of a client/ 
server system. For example, management services 

55 performed by the server occur on the server machine and are 
server-side operations. Client/server systems require com- 
munications and operations to take place across a network. 
ORBs facilitate these communications and operations across 
the network. 

60 Microsoft has developed DCOM (Distributed Component 
Object Model) to support inter-application communications 
across networked computer systems. Another technology 
standard for inter-object communications is CORBA 
(Common Object Request Broker Architecture) established 

65 by the Object Management Group (OMG) which is a 
consortium sponsored by many companies, including Digi- 
tal Equipment Corporation, Hewlett Packard, IBM and Sun 
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Microsystems, Inc. CORBA defines how messages from one 
object to another are to be formatted and bow to guarantee 
delivery. The messaging in CORBA is performed by Object 
Request Brokers (ORBs). ORBs receive messages, deter- 
mine the location of the receiving object, route the message 
to the receiving object, and perform all necessary platform 
and language translations. In object oriented technology, a 
message is typically a request sent to an object to change its 
state or to return a value. The object has encapsulated 
methods to implement the response to the received message. 
Through technology such as DCOM and CORBA, objects 
can communicate with remote objects residing in other 
computer platforms connected by a network. 

The existence of different ORBs from different developers 
has resulted in several different communication protocols for 
transmission and reception of messages across a network. 
For example, CORBA uses a communication protocol called 
Internet Intcr-ORB Protocol (IIOP). DCOM uses a commu- 
nication protocol called Object Remote Procedure Call 
(ORPC), and Voyager uses a communication protocol called 
Voyager Remote Messaging Protocol (VRMP). The com- 
munication protocol used by a particular ORB may be 
referred to as its native protocol or native format Conven- 
tional remote proxies generally have the communication 
protocol hard coded within the proxy. 

CORBA compliant ORBs utilize stubs and skeletons to 
provide inter-object communications across a network. The 
stub is on the requester side and sends messages across the 
network to a skeleton on the remote object side. The stub and 
skeleton take care of certain communication details for the 
proxy on the requester side and the object on the remote 
object side. CORBA compliant ORBs generally use a utility 
to generate a stub and skeleton for each class using infor- 
mation provided in an Interface Description Language (IDL) 
file for each object. 

Enterprise Java Beans (EJB) is an object oriented pro- 
gramming specification developed by Sun Microsystems for 
use with its Java computer programming language. When 
using EJB, certain mechanisms are interposed as an inter- 
mediate layer between a client object and a server object. 
This is generally accomplished by creating a wrapper class 
having the same methods as the object being wrapped and 
adding wrapping code in each method of the wrapper class. 
An example of the wrapping code would be adding security 
to the wrapped object such as limiting access to client 
objects with the proper password or key. Wrapper classes are 
generally generated at run time and add additional complex- 
ity to the distributed processing system in addition to 
negatively impacting system performance. 

In certain situations, existing software needs to be used 
with distributing computing systems. Many conventional 
ORBs require an interface for each class for proper com- 
munications across a network. A user may not have access 
to the source code or may be restricted by license as to 
modifying the source code. Thus, the user may not be able 
to add interfaces to class files within the existing software. 
Adding interfaces allows classes to be used remotely in the 
distributed computing system. 

SUMMARY OF THE INVENTION 

Accordingly, a need has arisen for a system and method 
for distributed processing in a computer network that pro- 
vides communications between objects distributed across 
the network. 

According to an embodiment of the present invention, a 
system for distributed processing in a computer network is 
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provided that includes, a client side object request broker 
executing on a client computer and a server-side object 
request broker executing on a server computer. Hie server 
computer is connected to the client computer through a 

5 network. A remote proxy generator dynamically generates 
remote proxy classes for client-side communications sup- 
port for communications between a client application and a 
server object. The remote proxy generator resides in the 
server-side object request broker and instantiates the remote 

10 proxy class to create a remote proxy object. A client-side 
type generator generates a client side type object for a class 
of the server object. The client-side type object provides 
access to methods of the server object. A client-side function 
generator generates one or more client-side function objects 

15 for providing a connection to one or more methods of the 
server object. The one or more client-side function objects 
correspond in number to the one or more methods of the 
server object. A client-side reference generator generates a 
client-side reference object for encoding messages sent 
between the remote proxy object and the server object into 
a format of a communication protocol used by the server- 
side object request broker. The distributed processing sys- 
tem further includes a client-side streamer generator that 
generates a set of streamer objects corresponding in number 

^ to the methods of the server object. Each streamer object 
encodes a method invocation request for an associated 
server method into the format of the communicator protocol 
used by the server-side object request broker. 

A server-side local reference generator generates a local 

30 reference object that includes an address of the server object 
and a type of the server object. A server-side type generator 
generates a server-side type object for the class of the server 
object. The server-side type address provides access to the 
methods of the server object. A server-side function genera- 

35 tor generates one or more server-side function objects cor- 
responding in number to the one or more client-side function 
objects. The one or more server-side function objects are 
linked to the server-side type object. 
The present invention provides various technical advan- 

40 tages over conventional systems for distributed processing 
in a computer network. For example, one technical advan- 
tage is providing communications between, objects in dif- 
ferent address spaces connected to a common network. The 
present invention also dynamically generates remote proxies 

45 and other objects to provide communications across the 
network. In addition, the present invention provides com- 
munications with remote server objects when a client appli- 
cation does not know the location of the server object and 
the communication protocol used by the server object. Other 

50 technical advantages may be readily apparent to one skilled 
in the art from the following figures, descriptions and 
claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 
ss For a more complete understanding of the present inven- 
tion and the advantages thereof, reference is now made to 
the following description taken in conjunction with the 
accompanying drawings in which like reference numbers 
indicate like features and wherein: 
60 FIG. 1 illustrates a block diagram of a distributed object 
management system; 

FIG. 2 illustrates a flow diagram of a method for deter- 
mining when to dynamically generate remote proxy classes; 
FIG. 3 illustrates a block diagram of a system for dynami- 
65 cally generating remote proxy classes; 

FIG. 4 illustrates a flow diagram of a method for dynami- 
cally generating remote proxy classes; 
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FIG. 5 illustrates a block diagram of a distributed com- 
puting system; 

FIG. 6 illustrates different communication layers within 
the distributed computing system; 

FIG. 7 illustrates a block diagram of the communication 
layers of the distributed computing system where a client- 
side object request broker provides a proxy layer and part of 
a reference layer; 

FIG. 8 illustrates additional details of the reference layer 
provided by the client-side object request broker; 

FIG. 9 illustrates a block diagram of additional details of 
the reference layer provided by a server-side object request 
broker; 

FIG. 10 illustrates a block diagram of a system for 
dynamically generating remote proxy classes and other 
objects for the distributed computing system; and 

FIG. 11 illustrates a block diagram of an interface gen- 
erator. 

DETAILED DESCRIPTION OF THE 
INVENTION 

Referring to FIG. 1, a distributed processing computer 
system generally indicated at 10 is illustrated that comprises 
one or more server systems 12 and one or more client 
systems 14. The client/server computer systems allow for 
decentralized computing including the ability to manipulate 
data which is resident on a remote system. The server system 
12 and client system 14 may comprise a personal computer, 
mini computer, main frame computer, or any other suitable 
computer type device. In a computer network environment, 
each computer is assigned a unique address. Therefore, if 
data, code or objects exist on a different computer, it exists 
in a different address space. 

The client system 14 requests access to data or services 
that may be contained on server system 12. Server system 12 
may then process the request and approve access as 
requested by client system 14. Client system 14 is connected 
to server system 12 via a distributed object management 
system 16 operating across a computer network. The dis- 
tributed object management system 16 handles the commu- 
nications between client system 14 and server system 12. 
Without distributed object management system 16, distrib- 
uted processing could not take place since client system 14 
would not be able to determine the location of or obtain 
access to the requested data or services. The distributed 
object management system 16 may comprise Voyager, a 
distributed network communications system developed by 
ObjectSpace, Inc., CORBA (Common Object Request Bro- 
ker Architecture), a technology for inter-object communica- 
tions developed by a consortium of companies, DCOM, an 
inter-application communications system for networked 
computers developed by Microsoft, RMI, an inter-object 
communications system for networked computers devel- 
oped by Sun Microsystems, Inc., or any other suitable 
distributed object management system. 

An object is an instance of a class within the programming 
methodology of object oriented programming. The present 
invention may be implemented using the Java language, 
developed by Sun MicroSystems, Inc., or any other suitable 
computer language. 

When an object class source code description is created in 
the Java language, it is stored on a storage device as a java 
file. Upon compilation, the object class executable code is 
represented as a class file on the storage device. When an 
object is needed, a new instance, as prescribed by the class 
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file is created, and it is then referred to as an object. Server 
system 12 may contain one or more subject objects 18 for 
which client system 14 may issue a request for access. In 
such a case, subject object 18 is the subject of client system's 

5 14 request. Client system 14 may contain one or more local 
objects 20. Local object 20 can itself be a subject object, and 
subject object 18 can itself be a local object depending on 
what computer, or address space, is making the request for 
access. For purposes of illustrating the present invention, 

10 local object 20 and subject object 18 exist in different 
address spaces. However, both local object 20 and subject 
object 18 could reside on the same computer and still invoke 
the system and method of the present invention. 
Local object 20 may request access to subject object 18. 

15 This request invokes the distributed object management 
system 16. In order to isolate the distributed processing 
communication requirements from local object 20, a remote 
proxy object 22 may be created on server system 12 and 
loaded onto client system 14. Remote proxy object 22 has an 

20 interface and list of methods identical to subject object 18. 
Remote proxy object 22 is so named since it is remote from 
subject object 18, and it provides a local representative for 
an object which may reside in a different address space. 
Remote proxies in general are responsible for encoding a 

25 request and its arguments and sending the encoded request 
to the subject object that may exist in a different address 
space. Remote proxies also hide the location of the subject 
object from the requesting local object. Therefore, any local 
object can assume, from an access point of view, that any 

30 object it needs is local. Local object 20 communicates with 
remote proxy object 22 which then communicates with 
subject object 18 via distributed object management system 
16. By doing this, local object 20 is unconcerned with the 
location of subject object 18. 

35 Currently, a system developer must anticipate all neces- 
sary remote proxies and create the remote proxy classes. 
Some distributed object management systems have a utility 
which augments the build process by allowing remote proxy 
classes to be built when the system is compiled. Although 

40 this process minimizes the system developer's effort, it still 
involves system developer intervention, computer resources 
and time. Another disadvantage with current distributed 
object management systems is that these remote proxy 
classes must be kept in sync with the subject classes as the 

45 subject classes and interfaces are modified. Another disad- 
vantage with current distributed object management systems 
is that all remote proxy classes must be stored on the 
computer and available for use when needed. This creates 
high overhead in developer effort, computer storage and 

50 processing requirements. 

In contrast, a system constructed using the principles 
outlined in this patent application dynamically generates 
remote proxy classes as needed at run-time. There are 
several advantages of this method. The primary advantage is 

55 reduced system development time since the system devel- 
oper does not have to manually generate remote proxy 
classes when the system is initially compiled or manually 
regenerate remote proxy classes each time a subject object 
class is modified. The system also reduces computer pro- 

60 gram storage requirements since remote proxy classes are 
not a permanent part of the operating environment. It also 
minimizes compile and load time for the computer program 
since remote proxy classes do not have to be generated at 
compile and load time. In order to optimize system 

65 performance, generated remote proxy classes remain in 
memory until the distributed object management system is 
shut down. 
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Dynamic Generation of Remote Proxies 

Referring again to FIG. 1, the dynamic generation of 
remote proxies may be accomplished by parsing the class or 
Java file for subject object 18 and creating a .java file for 
remote proxy object 22 which contains the interfaces and 
methods of the subject object 18. The Java compiler may 
then be invoked to compile the .java file into a .class file for 
remote proxy object 22. The compiled .class file can then be 
loaded into the computer system via a class loader which is 
a standard element in a Java environment. A .class file must 
be loaded before it is available for use by distributed 
processing computer system 10. Once the .class file is 
loaded, a new instance of the compiled .class file may be 
created which will be remote proxy object 22. 

The process of parsing the subject object 18 class (subject 
class 19) or .java file, creating a source code file for remote 
proxy class 23, compiling, loading, and creating a new 
instance may be excessively slow at run-time. In order to 
address this issue, a reflection process may be used on 
subject object 18 to determine its name, interfaces and list of 
methods and then to directly generate the byte codes that 
define the class of subject object 18. The generated byte 
codes represent subject class 19. The byte codes are equiva- 
lent to the executable code stored in a .class file. The byte 
codes can then be loaded into the computer system memory 
with the class loader. This embodiment eliminates the need 
to parse the .class file, create a .java source code file, and 
shell out the .java file to a compiler since the byte code 
generation process occurs as part of the dynamic generation 
of remote proxies. This entire process of dynamic generation 
of remote proxies will be discussed in detail with reference 
to FIGS. 2, 3 and 4. 

Referring to FIG. 2, the process of determining whether a 
remote proxy is necessary is invoked via a request from local 
object 20 for access to subject object 18. The method begins 
at step 24 where local object 20 on client system 14 requests 
access to subject object 18 on server system 12. This request 
could be for any object whether it is local or remote and in 
a different address space. The system generates and utilizes 
remote proxy objects in all inter-object communication to 
provide additional processing support. Thus, any communi- 
cation between objects, regardless of their location, utilizes 
remote proxy objects. These remote proxy objects act as a 
middle man between the requested object and the requesting 
object to provide additional processing functionality such as 
increased security. 

Referring again to FIG. 2, the method then proceeds to 
step 26 where the requested object is located on either client 
system 14 or server system 12. The method proceeds to step 
30 where a determination is made regarding the need for a 
remote proxy class. If remote proxy class 23 already exists 
on client system 14, then the method terminates since remote 
proxy classes are not removed from client system 14 until 
the distributed object management system 16 is shut down. 
However, if remote proxy class 23 does not exist on client 
system 14, the method then proceeds to step 32 where the 
byte codes representing remote proxy class 23 are generated 
on server system 12 and loaded into client system 14 
memory based on the name, interfaces and methods of 
subject object 18. A method for generating remote proxies is 
described in detail with reference to FIGS. 3 and 4. 

FIG. 3 is a functional diagram of the portions of distrib- 
uted object management system 16 that are used to create 
remote proxy classes as necessary. Remote proxy generation 
control module 34 is invoked at step 32 in FIG. 2. When the 
distributed object management system 16 invokes the 
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remote proxy generation control module 34, the method 
previously described has already determined that the remote 
proxy class 23 does not yet exist on client system 14. 
Remote proxy generation control module 34 generates 

5 remote proxy 22 on client system 14 so local object 20 can 
communicate with subject object 18 via distributed object 
management system 16. 

As previously discussed, in object oriented programming, 
an object is an instance of a class. Classes may be defined 

10 in a class hierarchy where each class inherits the attributes 
of all of its ancestors. Inheritance is a concept that maps 
related classes onto each other in a hierarchical way. This 
allows a descendant of a class to inherit all of its variables 
and methods from its ancestors as well as create its own. The 
immediate ancestor of a class is known as the class* super- 

15 class. Therefore, in order to determine all of a class's 
attributes, all of the class's ancestors, or superclasses, should 
be determined. 

To fully define a remote proxy for a subject object, remote 
proxies should be generated for each of the subject object's 

20 superclasses. By generating these superclass remote proxies, 
the remote proxy for the subject object will inherit all of the 
variables and methods of its ancestors, or superclasses. An 
alternative to generating superclass remote proxies includes 
adding all of the superclass methods and interface require- 

25 ments to the remote proxy class. By adding the superclass 
information to the remote proxy class, the need for gener- 
ating superclass remote proxies is eliminated. 

Referring again to FIG. 3, remote proxy generation con- 
trol module 34 first invokes reflection engine 36 to deter- 

30 mine information regarding subject class 19. The process of 
reflection operates on subject class 19 which is the Java 
.class file for subject object 18. Although for illustrative 
purposes, subject object 18 and its Java .class file, subject 
class 19, exist on server system 12, subject class 19 could 

35 exist on either client system 14 or server system 12. 
Therefore, the dynamic generation of remote proxy classes 
as described in the present invention could take place on 
either client system 14 or server system 12. 
Reflection is a process that determines what an object can 

40 do, how it is defined, and how it communicates with other 
objects. Reflection mirrors the public view of an object to 
collect information to facilitate the creation of proxies that 
resemble objects on the public view, but are very different 
internally, or privately. Trie public view of an object repre- 

45 sents the information external objects must know in order to 
communicate with the first object. Proxies need to be 
reflections, or duplicates on the surface, of objects since 
proxies perform specific tasks such as controlling access to 
or communications with the objects they represent. Thus, 

50 proxies need to look like the object on the outside, but on the 
inside, proxies contain unique computer code to accomplish 
their assigned function. The reflection process is only con- 
cerned with determining the public view of an object. 
Therefore, the information determined by the reflection 

55 process includes the following: name; list of implemented 
interfaces; list of methods; and superclass information. 

Continuing with FIG. 3, reflection engine 36 issues que- 
ries against subject class 19, which is the .class file for 
subject object 18, to determine each of subject class 19 

60 superclasses, its name, its interfaces, and each of its meth- 
ods. The results of these queries are temporarily stored 
within remote proxy generation control module 34 as JClass 
information 38. JClass information 38 is a temporary storage 
area for the name, superclasses, interfaces, and methods of 

65 subject class 19. JClass information 38 could also include 
the name, interfaces, and methods of each of subject class 19 
superclasses. 
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If the queries of reflection engine 36 determine that object and directly generates executable Java code without 

subject class 19 has no associated interfaces, reflection the need for the intermediate step of creating a Java source 

engine 36 invokes interface generator 250 to generate an file. This technique yields considerable time savings since 

interface for subject class 19. The generated interface is several steps are omitted. For example, like a Java compiler, 

associated with subject class 19 and added to JClass infor- 5 byte code generator 42 generates a hexadecimal "CAF- 

mation 38. Interface generator 250 will be discussed in detail EBABE" to indicate to the Java virtual machine that a Java 

with reference to FIG. 11. .class file begins at that point in memory. Byte code gen- 

If subject class 19 has superclasses, a remote proxy may crator 42 is constructed in such a way that the byte codes are 

be first generated for each superclass using the system and generated in the sequence required by the Java virtual 

method described with reference to the present invention. 10 machine. 

After the superclass remote proxies are generated, JClass For each Java construct, byte code generator 42 writes the 

information 38 contains the name, interface, and list of appropriate header information and byte codes representing 

methods for subject class 19. An alternate methodology for the Java construct into computer memory. Thus, there is a 

providing superclass methods and interfaces for the remote block of code, or bytes, for each Java construct. As described 

proxy class is to add all superclass method and interface * 5 above, JClass information 38 contains the computer code 

information to the remote proxy class. By doing this, the necessary for communications within distributed object 

need for separate superclass remote proxies is eliminated. management system 16. Byte code generator 42 translates 

Once the name, interface, methods, and superclass infor- this communications information into byte codes recogniz- 

mation are determined for subject class 19, a communication able to the Java virtual machine. When byte code generator 

enabling module 40 adds to JClass information 38 the 20 42 terminates, the string of hexadecimal bytes necessary to 

computer code necessary for remote proxy object 22 to define the proxy class has been stored in memory as remote 

communicate with subject object 18 via distributed object P^xy class 23 which is equivalent to an executable Java 

management system 16. The communication enabling mod- class file. The generated remote proxy class 23 is stored in 

ule 40 inserts the computer code into JClass information 38 memory and does not go through the system file procedure, 

which is the definition of all the information that remote 25 Remote proxy class 23 has a unique name which is derived 

proxy object 22 needs to function within distributed object &om subject class 19 name. For example, if subject class 19 

management system 16. is named "Fooxlass", its remote proxy class 23 name would 

Since a remote proxy's purpose is to communicate with a be ^ 00 — Proxy.class . 
subject object that may exist either in a different address , 0 Before remote proxy class 23 can be used, it must be 
space or in the same address space, the remote proxy loaded onto client system 14 utilizing a class loader 46. 
contains essentially the following information: interfaces Class loader 46 may comprise any number of suitable 
identical to the subject object; a list of methods identical to programs which exist in typical object oriented program- 
me subject object; and computer code necessary for the ming environments. The class loader 46 takes the generated 
remote proxy to communicate with the subject object. In an 3 , bytes of remote proxy class 23 stored m memory and loads 
alternate embodiment of the present invention, the remote ^em into a class structure which then can be instantiated to 
proxy would contain all of the information mentioned above create remote proxy object 22. 

and the interfaces and methods of all of the subject object's FIG. 4 is a flow diagram that illustrates the process of 

superclasses. generating a remote proxy when invoked by step 32 in FIG. 

At this point, JClass information 38 contains subject 40 2 and as represented in general by the block diagram in FIG. 

object's 18 name, interfaces, methods, and the computer 3. The method begms at step 48 where the reflection engine 

code necessary for communications within distributed 38 queries subject class 19 to determine its superclass. The 

object management system 16. JClass information 38 could method then proceeds to step 50 where a determination ts 

also contain the superclass information for subject object 18. made regarding the existence of a superclass for subject 

The next function invoked by remote proxy generation 45 class 19. If a superclass is found for subject class 19, then the 

control module 34 is byte code generator 42. The purpose of method proceeds to step 52 where a determination is made 

byte code generator 42 is to directly generate the executable regarding the existence of the remote proxy class on client 

code corresponding to JClass information 38. JClass infor- system 14 representing subject class' 19 superclass. If a 

mation 38 is the definition of the Java class of which remote remote proxy class does not exist for subject class' 19 

proxy object 22 is an instance. That is, JClass information 38 50 superclass, the method proceeds to step 54 where the remote 

is the definition of remote proxy class 23. Byte code proxy class is generated for subject class' 19 superclass by 

generator 42 reviews JClass information 38 and generates recursively invoking the remote proxy generation control 

the corresponding byte codes, or executable code, into module 34. Thus, step 54 recursively invokes the method 

remote proxy class 23 which is equivalent to a Java .class file illustrated in FIG. 4. 

except that it is not stored on a permanent storage device. 5S Referring to step 52, if the remote proxy class does exist 

Byte code generator 42 is a collection of Java classes that on client s y stem 14 for subject class' 19 superclass, then the 

are capable of taking the description of the needed proxy method proceeds to step 56 (described below) since remote 

class in JClass information 38 and directly generating the P^xy classes already exist for all of subject object's 18 

executable Java code in memory. The function of byte code superclasses, 

generator 42 is similar to that of a Java compiler. Like a Java 60 In an alternate embodiment of the present invention, 

compiler, byte code generator 42 generates executable Java instead of recursively generating remote proxy classes for 

code. However, the inputs are different. A compiler requires each of subject class 19 superclasses, the interfaces and 

a source code file containing a string of bytes that is the methods of each of subject class 19 superclasses are stored 

sequence of statements for a Java object definition. The in JClass information 38 and are later used in the generation 

string of bytes is parsed by the Java compiler and translated 65 of remote proxy class 23. In the alternate embodiment, steps 

into executable Java code. In contrast, byte code generator 48-54 would not exist in their current form. Instead, these 

42 takes general information regarding the needed Java steps would consist of determining the names, interfaces, 
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and methods of all of subject class 19 superclasses and 
storing the information in JClass information 38. 

Referring to step 50 if a superclass does not exist for 
subject object 18, then the method proceeds to step 56 where 
reflection engine 36 queries subject class 19 to determine 
subject class' 19 name and interface. The method proceeds 
to decisional step 57 where a decision is made regarding the 
existence of an interface for subject class 19. If an interface 
does not exist for subject class 19, the NO branch of 
decisional step 57 proceeds to step 59 where interface 
generator 250 generates an interface for subject class 19. 
The method then proceeds to step 58 (described below). 

If an interface does exist for subject class 19, the YES 
branch of decisional step 57 proceeds to step 58 where 
reflection engine 36 queries subject class 19 regarding its 
methods. Reflection engine 36 issues queries for each of 
subject class* 19 methods until all methods are determined. 
For each of subject class' 19 methods, the software system 
determines the method name, return type, parameters, and 
exceptions and stores the information in JClass information 
38. 

The method then proceeds to step 60 where reflection 
engine 36 creates JClass information 38 from the name, 
interface, and methods information determined in steps 56 
and 58. The method then proceeds to step 62 where com- 
munication enabling module 40 inserts in Jclass information 
38 the computer code, in the form of an expression tree, 
necessary for remote proxy object 22 to communicate with 
subject object 18 via distributed object management system 
16. 

The method then proceeds to step 64 where byte code 
generator 42 generates the executable code representing 
JClass information 38 into remote proxy class 23. The 
method then proceeds to step 66 where class loader 46 loads 
remote proxy class 23 onto client system 14 where it is now 
available for use. The method then proceeds to step 68 where 
remote proxy object 22 is generated as a new instance of 
remote proxy class 23 which was loaded in step 66. 

Communication Layers 

Referring to FIG. 5, a distributed computing system is 
generally indicated at 100. Distributed computing system 
100 may comprise a typical client/server system. Distributed 
computing system 100 includes a client system 102 and a 
server system 104 linked by a network 106. Distributed 
computing system 100 may be any suitable distributed 
processing system including the previously described dis- 
tributed processing computing system 10. Client system 102 
and server system 104 may be any suitable computing 
device such as a mainframe computer, personal computer, or 
portable computer. Network 106 may comprise an Internet 
or other suitable network connecting client system 102 with 
server system 104. Distributed computing system 100 also 
includes a client-side object request broker (ORB) 112 and 
a server-side object request broker (ORB) 114. Client-side 
ORB 112 executes on client system 102 and provides 
client-side communication support for distributed comput- 
ing system 100. Similarly, server-side ORB 114 executes on 
server system 104 and provides server-side communication 
support for distributed computing system 100. 

Client system 102 includes a client application 108 that 
accesses a server object 110 on server system 104. Server 
object 110 may also be referred to as a target object or 
requested object since server object 110 is the target of a 
request for access initiated by client application 108. Client 
application 108 may be an application resident on client 
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system 102, an application uploaded from server system 
104, an applet uploaded from server system 104, or any 
other suitable application or procedure. Client-side ORB 112 
and server-side ORB 114 communicate across network 106 

s to provide a communication link between client application 
108 on client system 102 and server object 110 on server 
system 104. Client-side ORB 112 and server-side ORB 114 
arc responsible for encoding messages into an on-the-wire 
format and decoding the message upon receipt. An example 

10 of this type of distributed computing system would be the 
World Wide Web operating across the Internet. "On-the-wire 
format" as used here refers to the format required for the 
communication protocol used by the receiving device or the 
receiving ORB. Client system 102 would typically be a 

15 personal computer connected to the Internet. Server system 
104 would typically be a web server hosting web pages and 
other network resources. Client-side ORB 112 may be 
resident on client system 102, or it may be uploaded from 
either server system 104 or any other computing device 

20 connected to network 106. 

Referring to FIG. 6, communication layers of distributed 
computing system 100 are generally indicated at 130. Com- 
munication layers 130 are the layers through which a 
request, or message, from client application 108 passes as it 

25 proceeds to server object 110. The messages sent between 
client application 108 and server object 110 may include a 
method invocation. The method invocation is a request from 
client application 108 to invoke a particular method on 
server object 110 and may include the server object name, 

30 the method name or number to be invoked, and any other 
arguments or data needed by the invoked method. Commu- 
nication layers 130 include an application layer 132, a proxy 
layer 134, a reference layer 136 and an object layer 138. 
Application layer 132 includes the primary application or 

35 procedure being executed by client system 102 and any 
interactions with an application controller such as a human 
operator at a computer terminal. An operating entity such as 
a human operator at a computer terminal interacts with the 
primary application or procedure being executed in appli- 

40 cation layer 132 on client system 102. Application layer 132 
communications with the proxy layer 134, 

Proxy layer 134 provides a local object on client system 
102 for a referenced server object 110 on server system 104. 

45 The local reference is a remote proxy that allows application 
layer 132 to ignore both the location of the server object 110 
and the communication details involved in communicating 
across network 106. The local object in proxy layer 134 is 
referred to as a remote proxy as previously described. Proxy 

50 layer 134 communicates with reference layer 136. 

Reference layer 136 allows client-side ORB 112 to com- 
municate with server-side ORB 114 using the communica- 
tion requirements of server-side ORB 114. The communi- 
cation requirements, or communication protocol, for server- 

55 side ORB 114 may not be identical to the communication 
requirements, or communication protocol, for client-side 
ORB 112. Thus, the communication details for distributed 
computing system 100 are kept in reference layer 136. 
Communication details include formulating the proper argu- 

60 menl list using commands and syntax that may be unique to 
client-side ORB 112 and encoding the resulting message 
into an on-the-wire format acceptable to server-side ORB 
114. Server-side ORB 114 receives and decodes the message 
from client-side ORB 112. Reference layer 136 comrauni- 

65 cates the message to the object layer 138. 

Object layer 138 receives the message and forwards it to 
server object 110. Server object 110 performs the procedure 
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or method requested by the message and forwards the result 
through communication layers 130 back to client application 
108. 

Reference Layer Abstraction 

Referring to FIG. 7, the communication layers 130 of 
distributed computing system 100 are illustrated. Many 
object-oriented environments utilize an interface as an inter- 
mediary for a requested object. The interface defines the 
public view of the requested object. The public view 
includes the arguments passed to and from the requested 10 
object in addition to the methods available for invocation. 
Interfaces are used to provide inheritance from multiple 
sources in the Java programming language. Although the 
present embodiment uses interfaces, other embodiments 
may not use interfaces. 15 

When client application 108 requests access to server 
object 110, a remote proxy 154 is generated for a server 
object 110 as previously described. Remote proxy 154 has 
an interface, IProxy 152. In one embodiment, remote proxy 
154 is generated from a standard base proxy class. Since 20 
Java allows inheritance from only one class, interfaces are 
used to allow remote proxy 154 to inherit methods and 
functionality from server object 110. Server object 110 has 
a server object interface 111. Remote proxy 154 may com- 
municate with server object 110 through server object inter- 25 
face 111. Traditional ORB implementations hardcode infor- 
mation about the communication protocol used to access 
server object 110 into the remote proxy. This requires 
different proxy implementations for each communication 
protocol used in distributed computing system 100. The 30 
present invention removes the hardcoded communication 
protocol information from remote proxy 154 and places it in 
reference layer 136 where a reference object 158 handles the 
communication protocol details. Reference object 158 is 
bound to remote proxy 154 as remote proxy 154 is gener- 35 
ated. Since reference object 158 resides in reference layer 
136, application layer 132 and proxy layer 134 do not need 
to know the particular communication protocol used to 
communicate with server object U0 or the specific location 
of server object 110. The communication protocol used by a 40 
particular ORB may be referred to as the ORB's native 
protocol or native format. In a particular embodiment, 
communication enabling module 40, referred to in FIG. 3, 
generates reference object 158 and places a link in remote 
proxy 154 to reference object 158. 45 

Reference object 158 has a separate implementation for 
each communication protocol used in distributed computing 
system 100. The different communication protocols may be 
any suitable communication protocol including HOP, 
ORPC, and VRMP as previously discussed. An instance of 
reference object 158 for the communication protocol asso- 
ciated with server object 110 is bound to remote proxy 154 
when remote proxy 154 is generated. 

In operation, client application 108 requests access to 
server object 110. The request for access may include 
invocation of a method of server object 110. This request 
causes server-side ORB 114 to generate a remote proxy 154 
for server object 110 as previously described except that in 
this embodiment, the computer code necessary for commu- 
nications is replaced by a link to an instance of reference 
object 158 for the communication protocol associated with 
server object U0. Remote proxy 154 is loaded onto client 
system 102 where it is available for use by client application 
108. Communications between client application 108 and 
server object 110 proceed by client application 108 com- 
municating with remote proxy 154 through its interface 
IProxy 152. 
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The method of remote proxy 154 invoked by client 
application 108 packages the arguments for the requested 
method and passes them to reference object 158 using its 
interface, IReference 156. Reference object 158 forwards 
the arguments to a streamer object (to be discussed in the 
following section) corresponding to the invoked method for 
encoding the arguments into a format corresponding to 
Reference object 158 identifies the communication protocol 
associated with server object 110. The arguments are passed 
through network 106 to server-side ORB 114. Server-side 
ORB 114 receives and decodes the arguments and then 
passes the arguments to server object 110 where the 
requested method is processed. Server object 110 passes a 
result through server-side ORB 114 across network 106 to 
reference object 158. Reference object 158 decodes the 
result and passes it to remote proxy 154. Remote proxy 154 
then makes the result available to client application 108. 

Function Objects and Streaming Architecture 

Referring to FIG. 8, additional details of the client-side 
ORB 112 implementation and communication details are 
illustrated. In addition to generating reference object 158, 
communication enabling module 40, discussed with refer- 
ence to FIG. 3, may also generate a type object 170 linked 
to proxy object 154 and inserted between proxy object 154 
and reference object 158. IVpe object 170 represents the 
class of server object 110. Type object 170 defines the 
methods on server object 110 to which remote proxy 154 has 
access. Type object 170 includes a set of function objects 
172 linked to type object 170. Set of function objects 172 
corresponds in number to a set of methods 190 associated 
with server object 110. There is one function object in set of 
function objects 172 for each method in set of methods 190. 
The function objects in set of function objects 172 are sorted 
in ascending order based on a position of the corresponding 
method in set of methods 190. By placing methods in 
function objects, each method can be invoked using a 
consistent interface. Set of function objects 172 represents 
the methods in set of methods 190 that client application 108 
may invoke. 

In operation, when remote proxy 154 receives a method 
invocation from client application 108, proxy object 154 
scans its associated type object 170 and invokes the function 
object in set of function objects 172 corresponding to the 
invoked method. Each function object in set of function 
objects 172 communicates the method invocation to refer- 
ence object 158 through its interface, IReference 156. In one 
embodiment, reference object 158 utilizes a set of streamers 
180 to format the method invocation into format consistent 
with the communication protocol used by server object 110. 
In that embodiment, there is one streamer per method per 
class. Thus, all instances of a class (all objects with the same 
class) use the same streamer. Set of streamers 180 handles 
the encoding and transmission of arguments and results 
according to the communication protocol used by the receiv- 
ing object or ORB. 

The streamers in set of streamers 180 correspond in 
number to the function objects in set of functions 172. In one 
embodiment, communication enabling module 40, discussed 

1 with reference to FIG. 3, links a streamer corresponding to 
each function object in set of function objects 172 to 
reference object 158. The streamer in set of streamers 180 
receives method arguments and a method number from 
reference object 158 and formats the method invocation for 

; communication across network 106. Passing method or 
function number instead of method name reduces the 
amount of data transmitted across network 106 thereby 
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reducing the amount of time used for data transmission. as a specialization of function object 210. EJB function 

Although some ORBs may receive and process a method objects 206 are used since creating an instance of a common 

number, other ORBs may require a method name. Set of class, EJB function, is less time-consuming and utilizes 

streamers 180 creates and sends serially a group of bytes fewer system resources than generating a wrapping class for 

corresponding to the method invocation initialed by client 5 certain wrapping approaches used in object-oriented envi- 

application 108. ronments such as Enterprise Java Beans. EJB function 

ammunicationenabUngmodule401iiiksstreamersinset objects 206 may also be considered specialized function 

of streamers 180 to reference object 158. In one objects or wrapping objects. Type object 204 forwards the 

embodiment, communication enabling module 40 verifies message to the appropriate EJB function object 206 for 

mat an instance of a corresponding streamer exists on client 10 preliminary processing. Preliminary common processing 

system 102 prior to linking reference object 158 to the may include security checking, error handling, transaction 

streamer. For example, if a method one streamer 182 has management, or any other suitable common functionality, 

already been instantiated for method one of the class asso- After the preliminary common processing is complete EJB 

ciated with server object 110, communication enabling Action object 206 invokes the requested method 190 in 

module 40 links reference object 158 to the method one server object 110. 

streamer 182. If method one streamer 182 has not been After server object 110 processes the method invocation, 
previously instantiated, communication enabling module 40 the result is sent back to client application 108 through 
instantiates a method one streamer 182 and links it to essentially the same communication path except that refer- 
reference object 158. Method 1 streamer 182 may include ence object 200 uses an appropriate streamer from set of 
the non-variable communications specific program code to 20 streamers 220 to encode the result into the appropriate 
provide communications between client-side ORB 112 and on-the-wire communication protocol format, and the stream- 
server-side ORB 114. Each streamer in set of streamers 180 ers in set of streamers 180 in client-side ORB 112 arc 
is connected to network 106 so that data may be transmitted bypassed. Client -side ORB 112 locates the appropriate ref- 
to server-side ORB 114, Upon receipt, server-side ORB 114 erence object 158 utilizing communication protocol infor- 
decodes the communication and forwards the method invo- 25 mation received with the result message. Set of streamers 
cation to the appropriate method in set of methods 190. 220 operates in the same way as set of streamers 180. 

Wrapping Mechanism CORBA Helperless Communications 

Referring to FIG. 9, details of server-side ORB 114 30 A particular implementation of an object request broker is 
implementation and communication support for distributed Common Object Request Broker Architecture (CORBA). 
computing system 100 are illustrated. Some object oriented CORBA classes and structures are derived from Interface 
environments use a wrapping approach to interpose an Description Language (IDL) definitions, and CORBA- 
intermediate layer between client objects and server objects. compliant ORBs provide a utility to generate code to rep- 
One such approach is Enterprise Java Bean Containers. In 3S resent these classes and structures in a format native to the 
the present invention, the generated classes associated with specific CORBA-compliant ORB implementation. Conven- 
certain wrapping approaches such as Enterprise Java Beans tional CORBA ORBs also use the IDL definitions to gen- 
are eliminated and the generated class functionality placed erate support classes including a client-side stub and server- 
in specialized function objects referred to as EJB function side skeleton. The client-side stub accepts local requests for 
objects. The generated class functionality may include secu- 4Q access to a server-side target object and encodes the request 
rity checking, error handling, transaction management, or for transmission across a network to the server-side skeleton, 
any other suitable common functionality. The server-side skeleton decodes incoming requests and 

Server-side ORB 114 includes a reference object 200, a forwards the decoded requests to the target object that 

local reference 202, a type object 204, and one or more EJB resides 00 the server system. 

function objects 206. Upon receipt of a message from 45 The present invention eliminates the need for stubs and 

client-side ORB 112, server-side ORB 114 obtains a refer- skeletons as used in conventional CORBA-compliant ORBs 

ence object 200 based on communication protocol informa- by using the classes and structures generated from the IDL 

tion included in the message. Reference object 200 is to provide an ORB-specific implementation of the IDL 

analogous to, and functions as, reference object 158. Thus, classes and structures that includes the information needed 

server-side ORB 114 locates a reference object 200 for the 50 to communicate with other ORBs. Thus, CORBA stubs and 

communication protocol used by server object 110. The skeletons are not generated. The code generation utility 

message received by server-side ORB 114 is formatted and inserts a type code and communication protocol information 

streamed by a streamer in set of streamers 220 specifically into each generated class. The type code identifies a struc- 

for receipt and processing by server-side ORB 114. Refer- rure corresponding to the original IDL definition and pro- 

ence object 200 decodes the message from the on-the-wire 55 vides communications support for communications between 

formal and reconstitutes the message for processing by CORBA and non-CORBA ORBs. 

server-side ORB 114. Reference object 200 then forwards When a remote invocation is made from a remote proxy 

the message to local reference 202. Local reference 202 154 m a client-side ORB 112 of the present invention, the 

includes address and type information for server object 110. reference layer 136 queries the generated class and deter- 

Using that information, local reference 202 locates the 60 mines the associated type code and communication protocol 

appropriate type object 204 for server object 110. Type information. The type code is used to identify the type object 

object 204 represents the class of server object 110 and 170 and the communication protocol information is used to 

includes a function object 207, 208, and 209 for each method determine an appropriate reference object 158 to be used to 

190 accessible by client application 108. format the request for transmission to a CORBA-compliant 
Type object 204 is generated by server-side ORB 114 at 65 server-side ORB 114. The appropriate reference object 158 

the same time server-side ORB 114 dynamically generates formats the request into HOP format. HOP is the commu- 

remote proxy 154. An EJB function object 206 is interposed nication protocol used by CORBA ORBs. The reference 
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object 158 uses a streamer from set of streamers 180 to Client-side reference generator 306 generates reference 

transmit the request across network 106 to server-side ORB object 158. Reference object 158 represents the cornmuni- 

114. cation protocol used by server-side ORB 114. Client-side 

When a remote invocation is received in a server-side reference generator 306 instantiates a standard reference 

ORB 114 of the present invention from a CORBA-compliant s class for the communication protocol utilized by server-side 

client-side ORB 112, the server-side ORB 114 queries the ORB 114. 

target object 110 to determine the expected format of the Client-side streamer generator 308 generates a set of 

request. Remote invocations are transmitted from the streamers 180. Set of streamers 180 corresponds in number 

CORBA-compliant client-side ORB 112 in HOP format. The t0 mc methods of server object 110. Each method of server 

reference object 158 in the server-side ORB 114 then 10 object 110 has an associated streamer object in set of 

decodes the request into the expected format and forwards streamers 180. Each streamer object formats and streams an 

the request to the target object 110. appropriate method invocation request for the associated 

Server-Side ORB Object Generation mcthod of ob j ect 110 Each mcthod on scrvcr 

« , . ™~ „ rt . * „_ _ . . M1 t , . 110 may require a different argument list. Thus, separate 

Referring to FIG. 10, server-side ORB 114 is dlustrated 15 strcamer ob . m uscd tQ accommodate me diffe rent 

summarizing the various object generation processes of argumen t lists 

server-side ORB 114 discussed with reference to FIGS. 1-9. f ^ objec( 1M 

Server-side ORB 114 mcludes , l remote prox 'generator * ^ ^ 

300, a chent-side type generator 302, a ^chent«de function £ J of Reamers 180, server-side ORB 114 uploads 

generator 304, a client-Side reference generate 306 a M p^et 0 f objects to client-side ORB 112 where they are 

chent-s.de streamer generator 308 a server^ reference P communicating with server object 110 

generator 309, a server-side local reference generator 310 a «^ embodiment, after 

server-s.de type generator 312, and a server-side funcUon & ^ 

generator 314. Upoc .reviving a reques fo access lo ^server * £ Q ^ ^ ^ 

objec 110, server-s.de ORB IU4 generates ^a set of ob ecu o M J ^generates type object 170, set of function 

be uploaded to chent-side ORB 112. This set of objects is /V _ ^, . ^ - , 0 J . . r- ^.^ ^ oro 1fift 

« • k . , nA ,. „ f „ M objects 172, reference object 158 and set ot streamers 180 

generated by remote proxy generator 300, client-side type J ' - J . # - . :^»;„„ 

* 1M i* * -j <C t*- * i/u ♦ and stores the generated items for use in communicating 

generator 302, client-side function generator 304, client-side & non iu 

reference generator 306, and cnenf-side streamer generator ™* to server ° b J ect 110 through server-side ORB 114. 

308. The uploaded set of objects is used by clienUide ORB 30 J*"™*** reference generator 309 generates reference 

112 for communications with server-side ORB 114 and object 200. Reference object 200 manages the decoding of 

access to server object 110. The uploaded set of objects messages and method invocations received by server-side 

includes proxy object 154, type object 170, set of function ORB 114. Reference object 200 also forwards the messages 

objects 172, reference object 158, and set of streamers 180. and method invocations to the corresponding type object 

In another embodiment, the aforementioned uploaded set of 35 204 associated with a server object referenced in the mes- 

objects is generated by the client-side ORB 112 using sa S es ^ method invocations. 

processes equivalent to those used by server-side ORB 114 Server-side local reference generator 310 generates local 

in response to transferring a remote proxy instance gener- reference 202 based on the name and type of server object 

ated by remote proxy generator 300 to the client-side ORB 110. Local reference 202 allows an incoming message 

112 4Q destined for server object 110 to communicate with a local 

Remote proxy generator 300 is similar in structure and reference 202 within server-side object request broker 114 

operation to remote proxy generation control module 34. In before proceeding to invoking a method on server object 

this embodiment, communication enabling module 40 H0« 

inserts information into the remote proxy class identifying Server-side type generator 312 generates type object 204 

the communication protocol utilized by server-side ORB 45 representing the class of server object 110. Type object 204 

114 so that reference object 158 may be located to encode is similar in structure and operation to type object 170. 

and send a message from client-side ORB 112 to server-side Server-side function generator 314 generates function 

ORB 114. Remote proxy generator 300 generates proxy objects 210 or specialized function objects such as EJBfunc- 

object 154. Remote proxy generator 300 may also invoke tion objects 206. Function objects 210 or EJB function 

interface generator 250 to remote enable classes without 50 objects 206 correspond in number to the methods of server 

interfaces. Interface generator 250 and remote enabling object 110. Each function object 210 or EJB function object 

classes without interfaces are discussed in the following 206 directly invokes a corresponding method on server 

section. object 110. Each EJBfunction object 206 is instantiated from 

Client-side type generator 302 generates type object 170 a standard EJBfunction class that provides common func- 

using class information obtained from server object 110. ss tionality in addition to the functionality of function object 

T^pe object 170 represents the class of server object 110 and 210. Unique functionality may be added to each EJBfunc- 

includes an array of function objects 172 that provide access tion object 206 after it has been instantiated to provide for 

to the methods of server object 110. unique processing needs included in function object 210. 

Client-side function generator 304 generates a set of Server-side function generator 314 generates function 

function objects 172 corresponding in number to the meth- 60 objects 210 or EJBfunction objects 206. 

ods of server object 110. Each method of server object 110 n . „ ... n , . T «,. rf ,„ 

, , . r, . .... , r A J , . , Remote Enabling Classes Without Interfaces 

has a corresponding function object m set or function objects & 

172. By placing the methods within function objects, a Referring to FIG. 11, an interface generator 250 is illus- 

standard object communication statement may be used trated for use in remote enabling classes without interfaces, 

which does not require knowledge of the location of server 65 A typical remote proxy 154 resides in client system 102 and 

object 110 or the communication protocol used to commu- communicates through network 106 with server object 110 

nicate with server object 110. using server object interface 111. Existing class files on 
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server system 104 may need to be used remotely by client 
application 108 on client system 102. Before the existing 
class file may be used remotely, it should have an interface 
in order to comply with the communication standards of 
typical ORBs. Interface generator 250 generates an interface s 
254 for a class file 252. Interfaces provide for inheritance 
from multiple sources and ease of method invocation. With- 
out interfaces, a complex procedure using reflection is used 
to invoke methods directly on objects. 

In one embodiment, interface generator 250 is a command 10 
line predevelopmcnt utility used to generate interfaces for 
classes on server system 104 that will be used remotely in 
distributed computing system 100. In that embodiment, the 
software developer knows that certain class files 252 will be 
used remotely. The software developer provides interface 15 
generator 250 with a list of class files 252 for which 
interfaces 254 are to be generated. 

Interface generator 250 includes a class reader 256, a 
reflection module 258, a naming module 260 and an inter- 
face generation module 262. Class reader 256 retrieves the 20 
first class file name from an input list and reads the associ- 
ated class 252 from a class repository. 

Reflection module 258 uses reflection on class 252 to 
determine a name of the class, public methods of the class, 
and a signature for each of the public methods of the class. 
The reflection process may be any suitable reflection process 
including Java reflection as previously described. The sig- 
nature of each public method includes a name of the method; 
arguments used by the method, a result value for the method, 
and exceptions of the method. 

Naming module 260 creates a name for interface 254 
using any suitable naming convention. In one embodiment, 
the name for interface 254 is created by prepending the letter 
"I" with the name of class 252. The interface Ixxx is 
generated for a class named xxx, where xxx is any class 
name. 

Interface generation module 262 generates an interface 
for class 252 using the name of class 252, the public methods 
of class 252, and the signature of each public method of class 40 
252. Interface 254 is then added to the class file repository 
where it is available for use within distributed computing 
system 100. 

In another embodiment, interface generator 250 is used 
during the previously described dynamic generation of 45 
remote proxies. In that embodiment, remote proxy genera- 
tion control module 34 searches for interfaces implemented 
by class 252 for which a remote proxy class 23 is being 
generated. The interfaces may include a standard interface 
such as java.rmi.Remote or com.objectspace.voyagerJRe- 50 
mote. In addition, the interface may include a default 
interface with an "I" name as previously described. If none 
of the interfaces is found, remote proxy generation control 
module 34 invokes interface generator 250 through reflec- 
tion engine 36 to generate an interface 254 for a specified 5 5 
class 252. After the interface 254 is generated, it is added to 
the class file repository where it is available for use with an 
object having a class of class 252 and when instantiating the 
remote proxy class 23 to give remote proxy object 22. 

Thus, it is apparent that there has been provided io 60 
accordance with the present invention a system and method 
for remote enabling classes without interfaces that satisfies 
the advantages set forth above. Although the present inven- 
tion and its advantages have been described in detail, it 
should be understood that various changes, substitutions, 65 
and alterations may be readily apparent to those skilled in 
the art and may be made herein without departing from the 
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spirit and the scope of the present invention as defined by the 
following claims. 
What is claimed is: 

1. A system for distributed processing in a computer 
network, comprising: 

a remote proxy generator operable to dynamically gener- 
ate at runtime remote proxy classes to provide client- 
side communication support for communications 
between a client application and a server object, the 
remote proxy generator included in a server-side object 
request broker, the remote proxy class instantiated to 
create a remote proxy object, the remote proxy object 
providing a client-side representative of the server 
object; 

a client-side type generator operable to generate a client- 
side type object for a class of the server object, the 
client-side type object providing access to methods of 
the server object; 

a client-side function generator operable to generate one 
or more client-side function objects, the one or more 
client-side function objects corresponding in number to 
one or more methods of the server object, the one or 
more client-side function objects linked to the client- 
side type object and providing a connection to the one 
or more methods of the server object; 

a client-side reference generator operable to generate a 
client-side reference object, the client-side reference 
object identifying a communication protocol used by 
the server object, the client-side reference object 
accessed by the one or more client-side function 
objects; 

a client -side streamer generator operable to generate a set 
of streamer objects, the set of streamer objects corre- 
sponding in number to the methods of the server object, 
each streamer object in the set of streamer objects 
operable to encode a method invocation request for an 
associated server method into a format of the commu- 
nication protocol used by the server object, the one or 
more streamer objects accessed by the client-side ref- 
erence object; 

a server-side reference generator operable to generate a 
server-side reference object for managing decoding of 
messages and method invocations into a format pro- 
cessable by the server-side object request broker and 
for managing encoding of result messages for trans- 
mission to a client-side object request broker; 

a server-side local reference generator operable to gener- 
ate a local reference object contained within the server- 
side object request broker, the local reference including 
an address of the server object and a type of the server 
object; 

a server-side type generator operable to generate a server- 
side type object for the class of the server object, the 
server-side type object providing access to the methods 
of the server object, the server-side type object 
accessed by the server-side reference object using the 
local reference object; and 

a server-side function generator operable to generate one 
or more server-side function objects, the one or more 
server-side function objects corresponding in number 
to the one or more client-side function objects, the one 
or more server-side function objects linked to the 
server-side type object and providing access to methods 
of the server object. 

2. The system of claim 1, wherein the remote proxy 
generator further comprises: 
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a reflection engine operable to determine a name, 
interfaces, methods and superclass information of the 
server object; 

a communications enabling module operable to insert a 
communication protocol identifier in the remote proxy s 
class for use in locating a client-side reference object 
for the identified communication protocol; and 

a byte code generator operable to generate the executable 
computer code representing the remote proxy class. 

3. The system of claim 1, further comprising a determi- 10 
nation module operable to determine whether the remote 
proxy class needs to be generated in response to communi- 
cations between the client application and the server object 
by determining if the server object resides in a different 
address space and by determining if a remote proxy class has 
already been generated for the server object. 

4. The system of claim 1, further comprising a determi- 
nation module operable to determine whether a remote 
proxy class needs to be generated in response to communi- 
cations between the client application and the server object 
by determining if a remote proxy class has already been 20 
generated for the server object. 

5. The system of claim 1, further comprising a class loader 
operable to load the generated remote proxy class into the 
client-side object request broker. 

6. The system of claim 1, wherein the remote proxy 25 
generator is utilized by a distributed computing system to 
generate remote proxy classes for all inter-object commu- 
nication including both inter-address space and intra-address 
space communications. 

7. The system of claim 1, wherein the remote proxy 30 
object, the client-side type object, the one or more client- 
side function objects, the client-side reference object, and 
the set of streamer objects are generated by the server-side 
object request broker and uploaded to the client-side object 
request broker. 

8. The system of claim 1, wherein the client-side type 
object represents the class of the server object and includes 
an array of function objects corresponding to the methods of 
the server object. 

9. The system of claim 1, wherein the server-side refer- 
ence object, the local reference object, the server-side type 4 ° 
object, and the one or more server-side function objects are 
generated by the server-side object request broker and 
remain part of the server-side object request broker. 

10. The system of claim 1, wherein the local reference 
object provides a link between the server-side object request 45 
broker and the server object. 

11. The system of claim 1, wherein the server-side type 
object represents the class of the server object and includes 
an array of function objects corresponding to the methods of 
the server object. 50 

12. The system of claim 1, wherein each streamer object 
in the set of streamer objects serially sends bytes of the 
encoded messages across the network to the server-side 
object request broker. 

13. The system of claim 1, wherein each streamer object 55 
in the set of streamer objects transmits a method number 
instead of a method name to the server-side object request 
broker. 

14. The system of claim 1, wherein the server-side func- 
tion generator interposes a wrapping object between the 60 
server-side type object and each of the one or more server- 
side function objects, the wrapping object providing basic 
common processing to each of the server-side function 
objects. 

15. The system of claim 14, wherein the basic common 65 
processing includes security checking, error handling, and 
transaction management. 



16. A method for distributed processing, in a computer 
network comprising: 

receiving a request for access to a server object on a server 
system by a client application on a client system; 

generating a remote proxy class for the server object by a 
server-side object request broker in response to the 
request for access; 

generating a client-side type object representing a class of 
the server object; 

generating one or more client-side function objects cor- 
responding in number to one or more methods of the 
server object, the one or more client-side function 
objects linked to the client-side type object and pro- 
viding access to methods of the server object; 

generating a client-side reference object identifying a 
communication protocol used by the server-side object 
request broker; 

generating a set of streamer objects corresponding in 
number to the one or more methods of the server object, 
each streamer object in the set of streamer objects 
encoding messages sent between the client application 
and the server object into the communication protocol 
used to communicate with the server object, the set of 
streamer objects linked to the client-side reference 
object; 

uploading the remote proxy class, the client-side type 
object, the one or more client-side function objects, the 
client-side reference object, and the set of streamers to 
a client-side object request broker, 

generating a server-side type object representing the class 
of the server object; and 

generating one or more server-side function objects cor- 
responding in number to the one or more methods of 
the server object, the one or more server-side function 
objects linked to the server-side type object and pro- 
viding access to the methods of the server object. 

17. The method of claim 16, further comprising: 
receiving a method invocation for a method of the server 

object from the client application in a remote proxy 
object in the client-side object request broker, the 
remote proxy object instantiated from the remote proxy 
class; 

receiving the method invocation in the client-side type 
object from the remote proxy object; 

receiving the method invocation in the client-side func- 
tion object corresponding to the invoked method; 

receiving the method invocation in the client-side refer- 
ence object; 

encoding the method invocation into a format for the 
communications protocol used by the server-side 
object request broker in the streamer object correspond- 
ing to the invoked method; 

transmitting the encoded method invocation through a 
network to the server-side object request broker; 

decoding the encoded method invocation into a format 
processable by the server-side object request broker; 

receiving the method invocation in the server-side type 
object corresponding to the class of the server object 
referenced in the method invocation; 

receiving the method invocation in the server-side func- 
tion object corresponding to the invoked method; and 

invoking the method of the server object referenced in the 
method invocation. 
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18. The method of claim 17, further comprising: 
forwarding the result of the method invocation to the 

client application. 

19. The method of claim 17, further comprising: 
generating a server-side reference objecl for managing the s 

decoding of the encoded method invocation. 

20. The method of claim 16, further comprising: 
generating a server-side local reference within the server- 
side object request broker, the server-side local refer- 1Q 
ence providing an address of the server object and a 
type of the server object. 

21. The method of claim 16, wherein the step of gener- 
ating a remote proxy class further comprising: 

reflecting the server object to determine the server 15 
object's name, interfaces, methods, and superclass 
information for use in generating the remote proxy 
class; 

inserting within the remote proxy class the computer code 
necessary to identify the communication protocol uti- 20 
lized for communications with the server-side object 
request broker; and 

generating the executable code representing the deter- 
mined server object name, interfaces, methods, super- 
class information, and communications computer code 25 
for the remote proxy class. 



22. The method of claim 16, further comprising: 
determining if a remote proxy class is required in 

response to communications between the client appli- 
cation and the server object by determining if the server 
object resides in a different address space and by 
determining if a remote proxy class has already been 
generated for the server object. 

23. The method of claim 16, further comprising deter- 
mining if a remote proxy class is required in response to 
communications between the client application and the 
server object by determining if a remote proxy class has 
already been generated for the server object. 

24. The method of claim 16, further comprising utilizing 
a class loader to load the generated remote proxy class onto 
a client system. 

25. The method of claim 16, further comprising: 
interposing a wrapping object between each of the one or 

more server-side function objects and the server-side 
type object, the wrapping object providing common 
processing to each of the server-side function objects; 
and 

forwarding the method invocation to a wrapping object 
associated with the server-side function object corre- 
sponding to the invoked method. 
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